1
2
Neste
Nei.
JSON er kun data, og hvis du inkluderer en kommentar, vil det også være data.
Du kan ha et angitt dataelement kalt "_comment" (eller noe) som skal ignoreres av apper som bruker JSON-dataene.
Du vil sannsynligvis være bedre å ha kommentaren i prosessene som genererer / mottar JSON, da de skal vite hva JSON-dataene vil være på forhånd, eller i det minste strukturen til den.
Men hvis du bestemte deg for å:
{
"_comment": "kommentarteksten kommer her ...",
"ordliste": {
"title": "eksempel ordliste",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Akronym": "SGML",
"Forkortelse": "ISO 8879: 1986",
"GlossDef": {
"para": "Et metamerkingsspråk som brukes til å lage markeringsspråk som DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markering"
}
}
}
}
}
|
Nei, kommentarer på skjemaet // ... eller / * ... * / er ikke tillatt i JSON. Dette svaret er basert på:
https://www.json.org
RFC 4627:
Applikasjonen / json Media Type for JavaScript Object Notation (JSON)
RFC 8259 JavaScript Object Notation (JSON) Data Interchange Format (super Mercedes RFCs 4627, 7158, 7159)
|
Ta med kommentarer hvis du velger; fjern dem med en minifier før du analyserer eller sender.
Jeg har nettopp sluppet JSON.minify () som fjerner kommentarer og mellomrom fra en blokk med JSON og gjør det til gyldig JSON som kan analyseres. Så du kan bruke det som:
JSON.parse (JSON.minify (my_str));
Da jeg slapp den, fikk jeg et enormt tilbakeslag av folk som ikke var enige med ideen om det, så jeg bestemte meg for å skrive et omfattende blogginnlegg om hvorfor kommentarer gir mening i JSON. Den inkluderer denne bemerkelsesverdige kommentaren fra skaperen av JSON:
Anta at du bruker JSON til å beholde konfigurasjonsfiler, som du vil kommentere. Gå videre og sett inn alle kommentarene du liker. Rør den deretter gjennom JSMin før du overleverer den til JSON-parseren din. - Douglas Crockford, 2012
Forhåpentligvis er det nyttig for de som er uenige i hvorfor JSON.minify () kan være nyttig.
|
Kommentarer ble fjernet fra JSON etter design.
Jeg fjernet kommentarer fra JSON fordi jeg så at folk brukte dem til å holde analysedirektiv, en praksis som ville ha ødelagt interoperabilitet. Jeg vet at mangelen på kommentarer gjør noen mennesker triste, men det burde det ikke.
Anta at du bruker JSON til å beholde konfigurasjonsfiler, som du vil kommentere. Gå videre og sett inn alle kommentarene du liker. Rør den deretter gjennom JSMin før du overleverer den til JSON-parseren din.
Kilde: Offentlig uttalelse av Douglas Crockford om G +
|
JSON støtter ikke kommentarer. Det var heller ikke ment å brukes til konfigurasjonsfiler der det skulle være behov for kommentarer.
Hjson er et konfigurasjonsfilformat for mennesker. Avslappet syntaks, færre feil, flere kommentarer.
Se hjson.github.io for JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ og C # bibliotek.
|
ANSVARSFRASKRIVELSE: DIN GARANTI er ugyldig
Som påpekt, utnytter dette hacket implementeringen av spesifikasjonen. Ikke alle JSON-parsere vil forstå denne typen JSON. Spesielt streaming av parsere vil kveles.
Det er en interessant nysgjerrighet, men du bør egentlig ikke bruke den til noe i det hele tatt. Nedenfor er det originale svaret.
Jeg har funnet et lite hack som lar deg plassere kommentarer i en JSON-fil som ikke vil påvirke analyseringen, eller endre dataene som blir representert på noen måte.
Det ser ut til at når du erklærer et objekt bokstavelig, kan du spesifisere to verdier med samme nøkkel, og den siste har forrang. Tro det eller ei, det viser seg at JSON-analysatorer fungerer på samme måte. Så vi kan bruke dette til å lage kommentarer i kilden JSON som ikke vil være til stede i en analysert objektrepresentasjon.
({a: 1, a: 2});
// => Objekt {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Lengde;
// => 1
Hvis vi bruker denne teknikken, kan den kommenterte JSON-filen din se slik ut:
{
"api_host": "Vertsnavnet til API-serveren din. Du kan også spesifisere porten.",
"api_host": "hodorhodor.com",
"retry_interval": "Intervallet i sekunder mellom forsøk på mislykkede API-anrop",
"prøv på nytt": 10,
"auth_token": "Autentiseringstokenet. Det er tilgjengelig i utviklerens dashbord under" Innstillinger "",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "En matrise som inneholder favorittnumrene mine til alle tider",
"favorittnummer": [19, 13, 53]
}
Ovennevnte kode er gyldig JSON. Hvis du analyserer det, får du et objekt som dette:
{
"api_host": "hodorhodor.com",
"prøv på nytt": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favoritt_nummer": [19,13,53]
}
Noe som betyr at det ikke er spor av kommentarene, og at de ikke vil ha rare bivirkninger.
Glad hacking!
|
Vurder å bruke YAML. Det er nesten et supersett av JSON (nesten alle gyldige JSON er gyldige YAML), og det tillater kommentarer.
|
Du kan ikke. I det minste er det min erfaring fra et raskt blikk på json.org.
JSON har sin syntaksvisualisert på den siden. Det er ikke noe notat om kommentarer.
|
Kommentarer er ikke en offisiell standard, selv om noen parsers støtter kommentarer i C ++ - stil. En som jeg bruker er JsonCpp. I eksemplene er det denne:
// Konfigurasjonsalternativer
{
// Standard koding for tekst
"koding": "UTF-8",
// Plugins lastet inn ved oppstart
"plug-ins": [
"python",
"c ++",
"rubin"
],
// Tabulatens innrykkstørrelse
"innrykk": {"lengde": 3, "use_space": sant}
}
jsonlint validerer ikke dette. Så kommentarer er en parserspesifikk utvidelse og ikke standard.
En annen parser er JSON5.
Et alternativ til JSON TOML.
Et ytterligere alternativ er jsonc.
Den siste versjonen av nlohmann / json har valgfri støtte for å ignorere kommentarer ved parsing.
|
Du bør skrive et JSON-skjema i stedet. JSON-skjema er for tiden en foreslått spesifikasjon for internettutkast. I tillegg til dokumentasjon, kan skjemaet også brukes til å validere JSON-dataene dine.
Eksempel:
{
"beskrivelse": "En person",
"type": "objekt",
"eiendommer":
{
"Navn":
{
"type": "streng"
},
"alder":
{
"type": "heltall",
"maksimum": 125
}
}
}
Du kan gi dokumentasjon ved hjelp av beskrivelsesskjemaattributtet.
|
Hvis du bruker Jackson som JSON-parser, kan du aktivere den for å tillate kommentarer:
ObjectMapper-kartlegger = ny ObjectMapper (). Konfigurer (Feature.ALLOW_COMMENTS, true);
Så kan du ha kommentarer som dette:
{
nøkkel: "verdi" // Kommentar
}
Og du kan også ha kommentarer som begynner med # ved å sette:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
Men generelt (som svart tidligere) tillater ikke spesifikasjonen kommentarer.
|
Dette er hva jeg fant i Google Firebase-dokumentasjonen som lar deg legge inn kommentarer i JSON:
{
"//": "Noen nettlesere vil bruke dette til å aktivere push-varsler.",
"//": "Det er det samme for alle prosjekter, dette er ikke prosjektets avsender-ID",
"gcm_sender_id": "1234567890"
}
|
NEI. JSON pleide å støtte kommentarer, men de ble misbrukt og fjernet fra standarden.
Fra skaperen av JSON:
Jeg fjernet kommentarer fra JSON fordi jeg så at folk brukte dem til å holde analysedirektiv, en praksis som ville ha ødelagt interoperabilitet. Jeg vet at mangelen på kommentarer gjør noen mennesker triste, men det burde det ikke. - Douglas Crockford, 2012
Det offisielle JSON-nettstedet er på JSON.org. JSON er definert som en standard av ECMA International. Det er alltid en andringsprosess for å få standarder revidert. Det er lite sannsynlig at merknader vil bli lagt til JSON-standarden av flere grunner.
JSON by design er et enkelt omvendt konstruert (menneskelig analysert) alternativ til XML. Det er forenklet til det punktet at merknader er unødvendige. Det er ikke engang et markeringsspråk. Målet er stabilitet og interoperabilitet.
Alle som forstår "has-a" forholdet mellom objektorientering kan forstå hvilken som helst JSON-struktur - det er hele poenget. Det er bare en rettet asyklisk graf (DAG) med nodekoder (nøkkel / verdipar), som er en nær universell datastruktur.
Denne eneste merknaden som kreves kan være "// Dette er DAG-koder". Nøkkelnavnene kan være så informative som nødvendig, og tillate vilkårlig semantisk arity.
Enhver plattform kan analysere JSON med bare noen få kodelinjer. XML krever komplekse OO-biblioteker som ikke er levedyktige på mange plattformer.
Kommentarer ville bare gjøre JSON mindre interoperabel. Det er rett og slett ingenting annet å legge til, med mindre det du virkelig trenger er et markeringsspråk (XML), og bryr deg ikke om dine vedvarende data lett kan parses.
MEN som skaperen av JSON også observerte, har det alltid vært JS-rørledningsstøtte for kommentarer:
Gå videre og sett inn alle kommentarene du liker.
Rør den deretter gjennom JSMin før du overleverer den til JSON-parseren din. - Douglas Crockford, 2012
|
Hvis tekstfilen din, som er en JSON-streng, skal leses av et eller annet program, hvor vanskelig ville det være å fjerne enten C- eller C ++ -kommentarer før du bruker den?
Svar: Det ville være en one liner. Hvis du gjør det, kan JSON-filer brukes som konfigurasjonsfiler.
|
Hvis du bruker Newtonsoft.Json-biblioteket med ASP.NET for å lese / deserialisere, kan du bruke kommentarer i JSON-innholdet:
// "name": "string"
// "id": int
eller
/* Dette er en
kommentareksempel * /
PS: Kommentarer med en linje støttes bare med 6+ versjoner av Newtonsoft Json.
Ytterligere merknader for folk som ikke kan tenke ut av boksen: Jeg bruker JSON-formatet for grunnleggende innstillinger i et ASP.NET-webapplikasjon jeg har laget. Jeg leser filen, konverterer den til innstillingsobjektet med Newtonsoft-biblioteket og bruker den når det er nødvendig.
Jeg foretrekker å skrive kommentarer om hver enkelt innstilling i selve JSON-filen, og jeg bryr meg virkelig ikke om integriteten til JSON-formatet så lenge biblioteket jeg bruker er OK med det.
Jeg tror dette er en "enklere å bruke / forstå" måte enn å lage en egen "settings.README" -fil og forklare innstillingene i den.
Hvis du har problemer med denne typen bruk; beklager, genien er ute av lampen. Folk ville finne andre bruksområder forJSON-format, og det er ingenting du kan gjøre med det.
|
Ideen bak JSON er å tilby enkel datautveksling mellom applikasjoner. Disse er vanligvis nettbaserte og språket er JavaScript.
Det tillater egentlig ikke kommentarer som sådan, men å sende en kommentar som et av navn- / verdiparene i dataene vil absolutt fungere, selv om dataene åpenbart må ignoreres eller håndteres spesifikt av analysekoden.
Alt som er sagt, det er ikke meningen at JSON-filen skal inneholde kommentarer i tradisjonell forstand. Det skal bare være dataene.
Ta en titt på JSON-nettstedet for mer informasjon.
|
JSON støtter ikke kommentarer innfødt, men du kan lage din egen dekoder eller i det minste forprosessor for å fjerne kommentarer, det er helt greit (så lenge du bare ignorerer kommentarer og ikke bruker dem til å veilede hvordan applikasjonen din skal behandle JSON-dataene ).
JSON har ikke kommentarer. En JSON-koderen MÅ IKKE sende kommentarer.
En JSON-dekoder KAN godta og ignorere kommentarer.
Kommentarer skal aldri brukes til å overføre noe meningsfylt. Det er
hva JSON er for.
Jf: Douglas Crockford, forfatter av JSON spec.
|
Jeg har nettopp møtt dette for konfigurasjonsfiler. Jeg vil ikke bruke XML (ordentlig, grafisk, stygg, vanskelig å lese), eller "ini" -format (ikke noe hierarki, ingen reell standard osv.) Eller Java "Egenskaper" -format (som .ini).
JSON kan gjøre alt de kan, men det er mye mindre ordentlig og mer leselig for mennesker - og parsers er enkle og allestedsnærværende på mange språk. Det er bare et datatre. Men kommentarer utenfor gruppen er ofte en nødvendighet for å dokumentere "standard" -konfigurasjoner og lignende. Konfigurasjoner skal aldri være "fullstendige dokumenter", men trær med lagrede data som kan være lesbare for mennesker når det er nødvendig.
Jeg antar at man kan bruke "#": "comment", for "valid" JSON.
|
Det avhenger av JSON-biblioteket ditt. Json.NET støtter JavaScript-stil kommentarer, / * kommisjon * /.
Se et annet spørsmål om Stack Overflow.
|
JSON gir mye mening for konfigurasjonsfiler og annen lokal bruk fordi den er allestedsnærværende og fordi den er mye enklere enn XML.
Hvis folk har sterke grunner mot å ha kommentarer i JSON når de kommuniserer data (uansett om de er gyldige eller ikke), kan JSON muligens deles i to:
JSON-COM: JSON på ledningen, eller regler som gjelder når du kommuniserer JSON-data.
JSON-DOC: JSON-dokument, eller JSON i filer eller lokalt. Regler som definerer et gyldig JSON-dokument.
JSON-DOC tillater kommentarer, og andre mindre forskjeller kan eksistere, for eksempel håndtering av mellomrom. Parsers kan enkelt konvertere fra en spesifikasjon til en annen.
Når det gjelder kommentaren fra Douglas Crockford om disse spørsmålene (referert av @Artur Czajka)
Anta at du bruker JSON til å beholde konfigurasjonsfiler, som du vil kommentere. Gå videre og sett inn alle kommentarene du liker. Rør den deretter gjennom JSMin før du overleverer den til JSON-parseren din.
Vi snakker om et generisk konfigurasjonsfilproblem (tverspråk / plattform), og han svarer med et JS-spesifikt verktøy!
Sikker på at en JSON-spesifikk minify kan implementeres på hvilket som helst språk,
men standardiser dette slik at det blir allestedsnærværende på tvers av parsere på alle språk og plattformer, slik at folk slutter å kaste bort tiden sin, mangler funksjonen fordi de har gode bruksområder for det, ser på problemet i nettfora og får folk til å fortelle dem at det er en dårlig idé eller foreslår at det er enkelt å implementere stripping av kommentarer fra tekstfiler.
Det andre problemet er interoperabilitet. Anta at du har et bibliotek eller API eller noen form for delsystem som har noen konfigurasjons- eller datafiler tilknyttet. Og dette delsystemet er
å få tilgang til fra forskjellige språk. Så går du for å fortelle folk: forresten
ikke glem å fjerne kommentarene fra JSON-filene før du sender dem til parseren!
|
Hvis du bruker JSON5, kan du inkludere kommentarer.
JSON5 er en foreslått utvidelse til JSON som tar sikte på å gjøre det lettere for mennesker å skrive og vedlikeholde for hånd. Det gjør dette ved å legge til noen minimale syntaksefunksjoner direkte fra ECMAScript 5.
|
Dojo Toolkit JavaScript-verktøysettet (i det minste fra versjon 1.4) lar deg inkludere kommentarer i JSON-en. Kommentarene kan være av / * * / format. Dojo Toolkit forbruker JSON via dojo.xhrGet () samtalen.
Andre JavaScript-verktøysett kan fungere på samme måte.
Dette kan være nyttig når du eksperimenterer med alternative datastrukturer (eller til og med datalister) før du velger et endelig alternativ.
|
JSON er ikke en innrammet protokoll. Det er et språkfritt format. Så en kommentars format er ikke definert for JSON.
Som mange har antydet, er det noen triks, for eksempel dupliserte nøkler eller en bestemt nøkkel _kommentar som du kan bruke. Det er opp til deg.
|
Du kan ha kommentarer i JSONP, men ikke i ren JSON. Jeg har nettopp brukt en time på å prøve å få programmet til å fungere med dette eksemplet fra Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Hvis du følger lenken, vil du se
? (/ * AAPLhistoriske OHLC-data fra Google Finance API * /
[
/ * Mai 2006 * /
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Siden jeg hadde en lignende fil i den lokale mappen min, var det ingen problemer med policyen for samme opprinnelse, så jeg bestemte meg for å bruke ren JSON ... og selvfølgelig mislyktes $ .getJSON lydløst på grunn av kommentarene.
Til slutt sendte jeg nettopp en manuell HTTP-forespørsel til adressen ovenfor og innså at innholdstypen var tekst / javascript, siden JSONP returnerer ren JavaScript. I dette tilfellet er kommentarer tillatt. Men søknaden min returnerte innholdstypeapplikasjon / json, så jeg måtte fjerne kommentarene.
|
Dette er et "kan du" -spørsmål. Og her er et "ja" svar.
Nei, du bør ikke bruke dupliserende objektmedlemmer til å fylle sidekanaldata til en JSON-koding. (Se "Navnene i et objekt SKAL være unike" i RFC).
Og ja, du kan sette inn kommentarer rundt JSON, som du kan analysere.
Men hvis du vil ha en måte å sette inn og trekke ut vilkårlige sidekanaldata til en gyldig JSON, er her et svar. Vi utnytter den ikke-unike representasjonen av data i en JSON-koding. Dette er tillatt * i seksjon to av RFC under "mellomrom er tillatt før eller etter noen av de seks strukturelle tegnene".
* RFC sier bare "mellomrom er tillatt før eller etter noen av de seks strukturelle tegnene", og nevner ikke eksplisitt strenger, tall, "falsk", "sann" og "null". Denne utelatelsen blir ignorert i ALLE implementeringer.
Først kanoniserer du JSON ved å minifisere den:
$ jsonMin = json_encode (json_decode ($ json));
Kod deretter kommentaren din i binær:
$ hex = pakke ut ('H *', $ kommentar);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Så steg din binære:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Her er utdataene dine:
$ jsonWithComment = $ steg. $ jsonMin;
|
Ansvarsfraskrivelse: Dette er dumt
Det er faktisk en måte å legge til kommentarer, og holde seg innenfor spesifikasjonen (ingen ekstra parser nødvendig). Det vil ikke resultere i menneskelesbare kommentarer uten noen form for analyse.
Du kan misbruke følgende:
Ubetydelig hvitt mellomrom er tillatt før eller etter noe token.
Mellomrom er hvilken som helst sekvens av en eller flere av følgende koder
poeng: tegnetabell (U + 0009), linjemating (U + 000A), vogn
retur (U + 000D), og mellomrom (U + 0020).
På en hacky måte kan du misbruke dette for å legge til en kommentar. For eksempel: start og avslutt kommentaren din med en fane. Kod kommentaren i base3 og bruk de andre tegnene til å representere dem. For eksempel.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hallo base tre i ASCII) Men i stedet for 0 bruk plass, for 1 bruk linjefôr og for 2 bruk vognretur.
Dette vil bare gi deg mye ulestelig mellomrom (med mindre du lager et IDE-plugin for å kode / dekode det på farten).
Jeg har aldri prøvd dette, av åpenbare grunner, og det burde du heller ikke.
|
JSON tillater ikke kommentarer i seg selv. Resonnementet er helt tåpelig, fordi du kan bruke JSON selv til å opprette kommentarer, noe som fjerner resonnementet helt, og laster tolkingsdatarommet uten god grunn i det hele tatt for nøyaktig samme resultat og potensielle problemer, som de er: en JSON fil med kommentarer.
Hvis du prøver å legge inn kommentarer (f.eks. Ved hjelp av // eller / * * / eller #), vil noen parsere mislykkes fordi dette strengt tatt ikke er
innenfor JSON-spesifikasjonen. Så du skal aldri gjøre det.
Her, for eksempel, hvor bildebehandlingssystemet mitt har lagret bildebeskrivelser og noe grunnleggende formatert (kommentar) informasjon relatert til dem (nederst):
{
"Notasjoner": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Ellipse",
"measureX": 356,
"mateY": 294,
"opasitet": 0,5,
"text": "Elliptisk område på toppen",
"textX": 333,
"textY": 265,
"title": "Notasjon 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rektangel",
"measureX": 109,
"mateY": 412,
"opasitet": 0,5,
"text": "Rect area \ non bottom",
"textX": 98,
"textY": 385,
"title": "Notasjon 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polygon",
"measureX": 102,
"omfang": 136,
"opasitet": 0,5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"jeg": 2,
"x": 102,
"y": 132
},
{
"jeg": 3,
"x": 83,
"y": 104
}
],
"text": "Enkel polygon",
"textX": 85,
"textY": 104,
"title": "Notasjon 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "JSON-bildedata:",
"c02": "-------------------------",
"c03": "",
"c04": "Disse dataene inneholder bilderotasjoner og beslektet område",
"c05": "valginformasjon som gir et middel for en",
"c06": "bildegalleri for å vise notasjoner med elliptisk,",
"c07": "indikasjoner på rektangulære, polygonale eller frihåndsområder",
"c08": "over et bilde som vises til en besøkende i galleriet.",
"c09": "",
"c10": "X- og Y-posisjonene er alle i bildetrom. Bildet",
"c11": "oppløsningen er gitt som imageXW og imageYW, som",
"c12": "du bruker til å skalere notasjonsområdene til deres rette",
"c13": "steder og størrelser for visning av bildet,",
"c14": "uansett skala.",
"c15": "",
"c16": "For ellipser er anker sentrum for ellipsen,",
"c17": "og omfanget er henholdsvis X- og Y-radiene.",
"c18": "",
"c19": "For rektangler er ankeret øverst til venstre og",
"c20": "extents er nederst til høyre.",
"c21": "",
"c22": "For frihånds- og polygonområdemodus, punktlisten",
"c23": "inneholder en serie med nummererte XY-punkter. Hvis området",
"c24": "er lukket, det siste punktet vil være det samme som",
"c25": "først, så alt du trenger å være opptatt av er å tegne",
"c26": "linjer mellom punktene i listen. Anker og omfang",
"c27": "er satt øverst til venstre og nederst til høyre for den angitte",
"c28": "region, og kan brukes som en forenklet rektangulær",
"c29": "detekter for museposisjonen over disse typene",
"c30": "av områder.",
"c31": "",
"c32": "Tekst- og tekstposisjonene gir grunnleggende posisjonering",
"c33": "informasjon som hjelper deg med å finne tekstinformasjonen",
"c34": "på en rimelig beliggenhet knyttet til området",
"c35": "indikasjon.",
"c36": "",
"c37": "Opasitet er en verdi mellom 0 og 1, hvor .5 representerer",
"c38": "en 50% ugjennomsiktig bakgrunn og 1.0 representerer en fullstendig ugjennomsiktig",
"c39": "bakteppe. Anbefaling er at regioner tegnes",
"c40": "bare hvis brukeren holder markøren over bildet,",
"c41": "og at teksten knyttet til regionene tegnes",
"c42": "bare hvis brukeren svever pekeren over det angitte",
"c43": "region."
}
}
|
Vi bruker strip-json-kommentarer for prosjektet vårt. Den støtter noe som:
/ *
* Beskrivelse
* /
{
// regnbuer
"enhjørning": / * ❤ * / "kake"
}
Bare npm install - lagre strip-json-comments for å installere og bruke den som:
var strip_json_comments = krever ('strip-json-comments')
var json = '{/ * regnbuer * / "enhjørning": "kake"}';
JSON.parse (strip_json_comments (json));
// => {enhjørning: 'kake'}
|
I mitt tilfelle må jeg bruke kommentarer til feilsøkingsformål rett før utgangen av JSON-strukturen. Så jeg bestemte meg for å bruke feilsøkingsinformasjon i HTTP-overskriften, for å unngå å bryte klienten:
header ("My-Json-Comment: Ja, jeg vet det er en løsning ;-)");
|
For å kutte et JSON-element i deler legger jeg til "dummy comment" -linjer:
{
"#############################" : "Del 1",
"data1": "verdi1",
"data2": "verdi2",
"##################################": "Del2",
"data4": "verdi3",
"data3": "verdi4"
}
|
1
2
Neste
Svært aktivt spørsmål. Tjen 10 rykte for å svare på dette spørsmålet. Omdømmekravet hjelper deg med å beskytte dette spørsmålet mot spam og ikke-svar-aktivitet.
Er ikke svaret du leter etter? Bla gjennom andre spørsmål merkede json-kommentarer eller still dine egne spørsmål.